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(57) Abstract: A switching and management infrastructure (SwMI) of a mobile communications network (TETRA PLMN) is con- 
nected to a gateway node (GGSN) by means of a standard interface (Gn) initially defined to be used in an other packet-mode com- 
munication network, in order to provide a packet-mode connection to an external communication network (PDN). As a consequence, 
the protocols and signaling messages already defined and developed for this standard interface (Gn) can be used for activating, de- 
activating and updating a logical packet data context between the infrastructure (SwMI) and the gateway packet node (GGSN) as 
well as to tunnel data packets therebetween. Also standard gateway packet node (GGSN) and all the existing interworking function 
thereof can be used for providing packet data services and interworking for the mobile network (TETRA PLMN). Thereby the need 
for developing and defining a special packet data routing and interworking for the mobile network will be avoided or minimized. On 
the other hand, the packet data services and protocols as well as the mobility management already developed for the switching and 
management infrastructure (SwMI) can be utilized. 
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Packet data s rvic in a mobile communications syst m 

Field of the invention 

The invention relates to packet-mode transmission in a mobile 
communications system. 

5 Background of the invention 

Mobile communications systems refer generally to any telecommu- 
nications system which enables a wireless communication when users are 
moving within the service area of the system. A typical mobile communications 
system is a public land mobile network (PLMIM). Often the mobile communica- 

10 tions network is an access network providing a user with a wireless access to 
external networks, hosts, or services offered by specific service providers. 

TETRA (TErrestrial Trunked RAdio) is a standard defined by ETSI 
(European Telecommunications Standard Institute) for digital professional mo- 
bile radio or private mobile radio (PMR) systems. The TETRA system is devel- 

15 oped primarily for professional and governmental users, such as police, mili- 
tary forces, oil plants, etc. 

One of the main targets in the development of mobile communica- 
tions networks is to provide new data communication services, such as packet 
data communication, and especially IP (Internet protocol) services. Therefore, 

20 a new TETRA packet data protocol (PDP) is under standardization in ETSI. 
The TETRA PDP will extend the conventional TETRA network to work as an 
IP subnet. 

The TETRA PDP extends data communication services by provid- 
ing increased capacity and usability for the TETRA. TETRA packet data is built 

25 on top of the basic TETRA radio link protocol stack and provides service 
mechanisms to convey different higher layer protocols. The network layer 
protocols supported by the TETRA PDP include Internet Protocol (IP) versions 
4 and 6. Thus the TETRA packet data extends the TETRA network to act as 
an IP subnet in the mobile IP scheme, which enables application programmers 

30 to build their applications in a well standardized environment. 

In the draft specifications there are defined only two reference 
points for the TETRA PDP. These reference points are between an IP packet 
mode equipment (TE) and a mobile termination (MT) and between MT and 
TETRA Switching and Management Infrastructure (SwMI), respectively. In 

35 other words, the draft specifications of ETSI define how TETRA PDP operates 
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from the point of vi w of the air interface and how to connect an IP packet- 
mode terminal equipment TE (e.g. PC or laptop) to a TETRA mobile terminal 
MT. No reference points inside the SwMI nor between the SwMI and an exter- 
nal IP network have been defined. In other words, the draft ETSI specifications 

5 do not define how to connect the TETRA PDP to the external IP networks 
which accommodate the IP services the user is interested in. As a conse- 
quence, the internal structure of the SwMI and its interworking with external IP 
networks is dependent on implementation. 

In this context the interconnectivity of the TETRA PDP can be di- 

10 vided into three parts: 1) Interworking with external IP Networks, e.g. the Inter- 
net and private intranets; 2) Interworking between separate TETRA networks; 
and 3) Interworking between the TETRA PDP and other mobile communica- 
tions networks. 

In the interworking between the TETRA PDP and external IP net- 
15 works, users 1 requirements for the TETRA PDP may vary a lot. The basic need 
is naturally the same: a user wants to use IP-based applications located on an 
external IP network, either on the Internet or on an intranet. From the user's 
perspective a network which resides between a user terminal and application 
services is merely a transport media for IP datagrams. However, even if the 
20 basic functionality is the same, the way the connection is established and 
packets are routed from one network to another varies. 

When the PDP context is established (i.e. the subscriber's IP ad- 
dress is activated and data can be transferred), the following issues may vary 
among users: 1) Allocation of the IP address (e.g. whether a static or dynamic 
25 allocation is used, and whether the IP address is allocated from the operator's 
or customer's address space); 2) User authentication (e.g. the authentication 
method used, whether the authentication is carried out by the operator and/or 
the customer); 3) User authorization; 4) Encryption of the IP traffic (none, end- 
to-end encryption, encryption between inteworking networks); and 5) Tunnel- 
30 ing of the traffic. 

The routing needs may also be very different for different users: 
i) All IP packets from the mobile stations MS of a TETRA customer 
are routed to the customer's intranet, regardless of the IP destination address 
in the packets. In this case the customer's intranet provides all the IP services 
35 which the users want to use, for example access to the Internet is provided 
through the customer's own network. Possible solutions include tunneling 


WO 01/30092 PCT/FIOO/00905 

3 

protocols, such as the GRE, L2TP and IPSEC tunnel mode. Specific IP routing 
techniques may also be used, such as MPLS. 

ii) All IP packets from the mobile station of the TETRA customer are 
routed to the Internet through the TETRA operator's Internet gateway. In this 

5 case there is no direct connection from the TETRA operator's network to its 
customer's intranet but all IP packets from the MSs are routed to the Internet. 
This means that the TETRA operator works as an Internet Service Provider 
(ISP). 

iii) The TETRA operator provides IP-based services on their own IP 
10 network. In this case the operator has IP services on their own network and 

provides them for the TETRA customers. Such services could include e-mail, 
WAP services and services tailored for the customers. 

iv) The remaining needs may be combinations of the basic schemes 
described above. In this case the TETRA operator's customer uses services 

15 provided on several IP networks. For example, there are important services on 
the customer's own intranet, the TETRA operator provides some specific IP 
services on its own network, and Internet access is routed through the TETRA 
operator's Internet gateway. 

The IP interworking between TETRA networks should provide the 

20 TETRA subscribers with the possibility to use TETRA PDP services in multiple 
SwMIs, i.e. TETRA networks. For example, a user should be able to activate 
the PDP context for IP traffic in a home SwMI and then visit a foreign SwMI 
and continue using IP services without any additional arrangements. 

At present there are no implemented solutions fulfilling the inter- 

25 working needs described above. 

Disclosure of the Invention 

An object of the present invention is to improve the interconnecta- 
bility of a packet data access network to other networks. 

The object is achieved by a method and a network characterized by 
30 what is disclosed in the attached independent claims. Preferred embodiments 
of the invention are disclosed in the attached dependent claims. 

The basic idea of the present invention is to connect a switching 
and management infrastructure of a mobile communications network to a 
packet node by means of a standard interface initially defined to be used in an 
35 other packet mode communication network, in order to provide a packet-mode 
connection to an external communication network. As a consequence, the 
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protocols and signaling messages already defined and developed for this 
standard interface can be used for activating, deactivating and updating a logi- 
cal packet data context between the infrastructure and a gateway packet node 
as well as to tunnel data packets therebetween. Also a standard gateway 

5 packet node and all the existing interworking functions thereof can be used for 
providing packet data services and interworking in the mobile network. 
Thereby the need for developing and defining separate packet data routing 
and interworking in the mobile network will be avoided or minimized. On the 
other hand, the packet data services and protocols as well as the mobility 

10 management already developed for the switching and management infra- 
structure can be utilized. 

In the preferred embodiment of the invention the Gn interface of the 
GPRS is used as an interface between a TETRA switching and management 
infrastructure and a gateway GPRS support node (GGSN). The GGSN is re- 

15 sponsible for interworking with external networks, such as packet data net- 
works (PDN), GPRS networks, the universal mobile telecommunication system 
(UMTS), or with another TETRA network. The invention enables to use 
TETRA mobility management (MM) and TETRA home database (HDB) and 
TETRA visitor database (VDB) functions, instead of GPRS mobility manage- 

20 ment and HLR and VLR functions. The use of the Gn interface and the GGSN 
allows to utilize standard building blocks of the mobile packet data world and 
the mainstream wireless data implementations (GSM, GPRS) for many fea- 
tures, instead of implementing them within the TETRA switching and man- 
agement infrastructure. The present invention also provides access to the 

25 GGSN development path, since all the development of the GGSN made in the 
GPRS can be easily adopted to the TETRA system. 

Further, the Gp interface which has been defined between the 
SGSN and the GGSNs in the GPRS can be used for interworking between the 
GGSNs in separate TETRA PLMNs so that packet data can be tunneled from 

30 one TETRA network to another. 

Brief Description of the Drawings 

In the following, the invention will be described in greater detail by 
means of preferred embodiments with reference to the accompanying draw- 
ings, in which 

35 Figure 1 illustrates the transmission plane of the TETRA PDP, 
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Figure 2 illustrates the architects of th TETRA PDP using the 

GGSN, 

Figure 3 illustrates the transmission plane of the TETRA PDP using 
the GGSN, 

5 Figure 4 is a signaling diagram illustrating a PDP context activation 

procedure, 

Figure 5 is a signaling diagram illustrating an MS-originated PDP 
context deactivation procedure, 

Figure 6 is a signaling diagram illustrating an SwMI-originated PDP 
10 context deactivation procedure, 

Figure 7 illustrates an SwMI with two Gn gateways, 
Figure 8 is a signaling diagram illustrating an inter-Gn gateway lo- 
cation update, and 

Figure 9 illustrates IP interworking between separate TETRA 

15 PLMNs. 

Preferred Embodiments of the Invention 

Preferred embodiments of the invention will be described in the fol- 
lowing as implemented in a TETRA network using the Gn interface of the 
GPRS for interconnection to other networks, but the invention is not restricted 
20 to this concept. 

Firstly, the TETRA PDP architecture and the GPRS architecture ac- 
cording to the current ETSI specifications are illustrated, in order to facilitate 
the description of the invention. 

The TETRA PDP Architecture 

25 The basic TETRA network architecture is called a Switching and 

Management Infrastructure (SwMI). The SwMI includes all equipment and 
means which enable the users to communicate with each other via the SwMI. 
It should be noted that the exact structure and operation of the SwMI is not 
relevant to the invention. Generally, the SwMI may be any mobile network in- 

30 frastructure which provides switching and mobility management functions. The 
TETRA network architecture implemented by Nokia Inc. Finland, comprises 
digital exchanges DXT to which base stations BTS are connected. The TETRA 
utilizes a distributed subscriber database structure including a home database 
(HDB) which comprises permanent information about the individual and/or 

35 group subscribers in the subscriber's home network, and a visitor database 
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(VDB) which comprises temporary information about individual and/or group 
subscribers visiting the network. Each DXT is typically provided with a VDB. 
Some of the DXTs provide a gateway to other telecommunications networks. 

The SwMI communicates over an air interface R 0 with a TETRA 
5 mobile termination MT or a mobile station MS. The MT is connected to a ter- 
minal equipment TE through an interface R1 . Further, an intersystem interface 
(ISI) is defined in the TETRA standard for interconnecting different TETRA 
networks. 

The TETRA PDP extends the data communication services by pro- 
10 viding increased capacity and usability for the TETRA. The present scenario of 
the TETRA PDP is disclosed in ETS 300 392-2 clause 19 version ME 04, 
August 1999, which is incorporated herein as a reference. Figure 1 illustrates 
the protocol stacks of the TETRA packet data when an application using the IP 
protocol is located in a mobile station MS. The MS may be, for example, a 
15 combination of an IP packet mode Terminal Equipment (TE), such as a Per- 
sonal Computer (PC), and a TETRA Mobile Termination (MT) having an IP 
packet data support. The protocol stacks in the MS and the SwMI typically 
contain the following protocols: Subnetwork Dependent Convergence Protocol 
(SNDCP), Mobile Link Entity (MLE), Logical Link Control (LLC), Medium Ac- 
20 cess Control (MAC), and Air Interface Layer 1 (AM). 

The air interface layer 1 (AM) is defined in the TETRA specifica- 
tions and provides a physical TETRA channel over the air interface R 0 . The 
MAC controls the access signaling (request and grant) procedures of the radio 
channel, and the mapping of the LLC frames onto the TETRA physical chan- 
25 nel. Logical Link Control (LLC) layer provides a logical link between the MS 
and the SwMI. The MLE protocol discriminator entity (data transfer) routes 
TETRA packet data signaling and data to the corresponding TETRA Packet 
data service access point (SAP) at the peer entity (SwMI/MS). 

The TETRA packet data is built on top of the MLE layer of the basic 
30 TETRA protocol stack and provides service mechanisms to convey different 
higher layer protocols. The first protocol, introduced merely for the packet data 
service, is the SNDCP. The SNDCP is a TETRA-specific network layer proto- 
col that has two main functions: 1) to negotiate and maintain TETRA PDP 
contexts between the MS and the SwMI, and 2) to control the PDP data 
35 transfer between the MS and the SwMI. 
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Before th MS can gain access to any of the SNDCP s rvices, it 
goes first through a packet data registration procedure called PDP Context 
Activation. The PDP Context Activation is initiated by the MS. In the PDP 
Context Activation, a PDP address (e.g. an IPv4 address) and other parame- 

5 ters to be used during data transfer are negotiated, as well as the binding of 
the PDP address to a TETRA subscriber identity ITSI. A unique PDP context 
is established for each PDP address which is active on the network (i.e. ready 
to transmit or receive data). In addition to the PDP address and the ITSI, the 
PDP context includes an SNDCP service access point identifier (SN-SAP), or, 

10 more generally, an NSAPI (Network Service Access Point Identifier) through 
which the services of the SNDCP are available to the upper layer protocols. 
Two TETRA PDP contexts stored in the MS and the SwMI establish a logical 
connection therebetween. 

In Fig. 1 the application in the MS uses the IP protocol layer which 

15 is on top of the SNDCP layer. In the SwMI there is an IP routing and relaying 
layer. Although other protocols of the R 0 (and the R1) interface are well de- 
fined in the TETRA specifications, the implementation of the IP routing and 
relaying layer in the SwMI as well as the connection to external networks are 
outside the scope of the ETSI specifications. 

20 The GPRS Architecture 

The GPRS infrastructure according to the GPRS specifications 
comprises GPRS support nodes (GSNs), namely a GPRS gateway support 
node (GGSN) and a GPRS serving support node (SGSN). The main functions 
of the SGSN are to detect new GPRS mobile stations in its service area, han- 

25 die the process of registering the new MSs together with the GPRS registers, 
send/receive data packets to/from the GPRS MS, and keep a record of the lo- 
cation of the MSs within its service area. The subscription information is stored 
in a GPRS register (HLR) where the mapping between the mobile's identity 
(such as MS-ISDN or IMSI) and the PDP address is stored. The GPRS regis- 

30 ter acts as a database from which the SGSNs can ask whether a new MS in 
its area is allowed to join the GPRS network. The SGSNs and GGSNs within 
one PLMN are interconnected by an intra-operator backbone network which 
can be implemented, for example, by means of a local area network, such as 
an IP network. The interface between the SGSNs and GGSNs within one 

35 PLMN is the Gn interface defined in the ETSI/GSM 09.60 technical specifica- 
tion. The protocol between the GSN nodes in the GPRS backbone network at 
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th Gn interfac within one PLMN and at the Gp interface (th int rface be- 
tween the GSNs of different PLMNs) is called the GPRS Tunneling Protocol 
(GTP). The GTP allows multiprotocol packets to be tunneled through the 
GPRS backbone between the GSNs. 
5 The main functions of the GPRS gateway support node (GGSN) in- 

volve interaction with the external data network. The GGSN interconnects an 
operator's GPRS network to external systems, such as other operators' GPRS 
systems, data networks, such as an IP network (Internet) or an X.25 network, 
and service centers. The GGSN includes GPRS subscribers' PDP addresses 
10 and routing information, i.e. SGSN addresses. Routing information is used for 
GTP tunneling of the protocol data units (PDUs) from the external network to 
the current access point of the MS, i.e. to the serving SGSN. 

In order to access the GPRS services, the MS shall first make its 
presence known to the network by performing a GPRS attach. This operation 
15 establishes a logical link between the MS and the SGSN, and makes the MS 
available for SMS over the GPRS, paging via the SGSN, and notification of in- 
coming GPRS data. More particularly, when the MS attaches to the GPRS 
network, i.e. it performs the GPRS attach procedure, the SGSN creates a mo- 
bility management context (MM context), and a logical link LLC (Logical Link 
20 Control) is established between the MS and the SGSN in the protocol layer. 
The MM contexts are stored in the SGSN and the MS. The MM context of the 
SGSN may contain subscriber data, such as the subscriber's IMSI 
(International Mobile Subscriber Identity), TLLI, and location and routing infor- 
mation, etc. 

25 In order to send and receive GPRS data, the MS shall activate the 

packet data address it wants to use by requesting a PDP activation procedure. 
This operation makes the MS known in the corresponding GGSN, and inter- 
working with external data networks can commence. More particularly, one or 
more PDP contexts are created in the MS, the GGSN and the SGSN, and 

30 stored in the serving SGSN in connection with the MM context. The PDP con- 
text defines different data transmission parameters, such as PDP type (e.g. 
X.25 or IP), PDP address (e.g. IP address), quality of service QoS and NSAPI 
(Network Sen/ice Access Point Identifier). Two associated PDP contexts in 
different GSN nodes define a GTP tunnel. The tunnel is identified with a Tun- 

35 nel ID (TID) which consists of the IMSI and the NSAPI. The MS activates the 
PDU context with a specific message, Activate PDP Context Requ st, in which 
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it gives information on th TLLI, PDP type, PDP address, required QoS and 
NSAPI, and, optionally^the access point name APN. The SGSN sends a cre- 
ate PDP context message to the GGSN, which creates the PDP context and 
sends it to the SGSN. The SGSN sends the PDP context to the MS in an Acti- 

5 vate PDP Context Response message, and a virtual connection or link be- 
tween the MS and the GGSN is established. As a result, the SGSN forwards 
all the data packets from the MS to the GGSN, and the GGSN forwards to the 
SGSN all data packets received form the external network and addressed to 
the MS. The PDP context is stored in the MS, the SGSN and the GGSN. 

10 When the MS roams to the area of a new SGSN, the new SGSN requests the 
MM and PDP contexts from the old SGSN. 

The TETRA PDP having the Gn Interface and the GGSN 

The system architecture according the preferred embodiment of the 
invention is illustrated in Figure 2. A basic TETRA network employing packet 
15 data protocol is interconnected to other packet data networks (PDN), an exter- 
nal host, or to other communications networks by means of the Gn interface 
and the GPRS gateway support node (GGSN) of the General Packet Radio 
Sen/ice (GPRS). 

In Figure 2 the GGSN is located in a private IP network called an 

20 Intra-PLMN Backbone. The combination of the SwMI and the Intra-PLMN 
Backbone is called a TETRA PLMN. The whole TETRA PLMN is usually con- 
trolled by one TETRA operator. The SwMI and the Intra-PLMN Backbone are 
interconnected with the Gn interface defined in the ETSI GPRS specifications. 
However, the SGSN and the mobility management features of the GPRS are 

25 not utilized in the TETRA PLMN according to the invention. This approach en- 
ables to use TETRA Mobility Management (MM) and TETRA Home DataBase 
(HDB) and Visitor Database functions instead of the GPRS MM, HLR and VLR 
functions. Thus, no new or modified mobility features are required in the 
TETRA SwMI. On the other hand, the standard GPRS GGSN can be used for 

30 interconnecting the TETRA PDP to other networks instead of implementing 
these with TETRA specific solutions within the TETRA network. This results in 
significantly lower costs and less development and standardization work. All 
future development in the GPRS can be immediately introduced into the 
TETRA PDP. The minimum requirement in the TETRA SwMI is that the IP 

35 routing and relaying layer is modified to support, at least in some extent, the 
Gn interface and to adapt it to the TETRA PDP. 
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Thus, the main functions of the SwMI may includ th standard 
functions of the TETRA SwMI, namely network access control, mobility man- 
agement, radio resource management, base station functions, and HDB/VDB 
functions, as well as the functionality which provides the Gn interface for the 
5 GGSN. The GGSN, on the other hand, provides the interworking with external 
IP networks, such as IP address allocation, IP routing, IP user authentication, 
IP tunneling, and IP encryption. 

The legends in Figure 2 have the following meanings: 

TETRA PLMN: A TETRA network which is a combination of a 
10 TETRA SwMI and an Intra-PLMN Backbone. 

SwMI: A TETRA Switching and Management Infrastructure. 

HDB: A database which comprises information about the individual 
and/or group subscribers and is located in the subscriber's home SwMI. 

GGSN: A Gateway GPRS Support Node. 
15 Intra-PLMN Backbone: A private IP network interconnecting IP net- 

work nodes, such as GGSNs. 

PDN: An IP Packet Data Network, such as the Internet or a private 

intranet. 

Host: An IP host computer, such as an e-mail server or an ordinary 

20 PC. 

R1: The TETRA reference point between the packet mode TE and 

the MT. 

RO: The reference point on the TETRA air interface for IP packet 

data. 

25 Gn, here: The reference point between the SwMI and the GGSN 

within the same TETRA PLMN. 

G/ f here: The reference point between an Intra-PLMN Backbone 
and an external IP PDN. 

Figure 3 illustrates the transmission and signaling planes between 
30 the TETRA PDP and the GGSN. The protocol structure is a combination of the 
transmission planes described in the TETRA and GPRS specifications. The 
connection is generated by a relay function in the SwMI, which relays PDP 
PDUs between the R 0 and Gn interfaces. 

The TETRA protocol stacks were described above with reference to 
35 Figure 1. In the Gn interface the GPRS Tunneling Protocol (GTP) tunnels the 
the user data and the signaling messages between the SwMI and the GGSN. 
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The User Datagram Protocol (UDP) and the Transmission Control Protocol 
(TCP) are alternative protocols which can be used with the underlying IP layer 
to transfer GTP signaling between the SwMI and the GGSN. Layer 1 (L1) and 
Layer 2 (L2) are physical and data link layers at the bottom of the protocol 
5 stack. 

The GTP protocol across the Gn interface is defined in the ETSI 
GSM 09.60 technical specification. However, only some of the signaling mes- 
sages defined for the GPRS are necessarily required for the GTP signaling 
between the SwMI and the GGSN in the TETRA system of Figs. 2 and 3. It 

10 seems to be necessary to support at least the following GTP signaling mes- 
sages: Create PDP Context Request, Create PDP Context Response, Update 
PDP Context Request, Update PDP Context Response, Delete PDP Context 
Request and Delete PDP Context Response. Also the following messages 
should preferably be supported: Echo Request, Echo Response, Version Not 

15 Supported and Error Indication. 

In the following, examples of the PDP context activation and deacti- 
vation procedures utilizing standard TETRA PDP and GPRS signaling mes- 
sages will be described. 

PDP Context Activation Procedure 

20 A successful PDP Context Activation procedure is illustrated in Fig- 

ure 4. Each numbered step is explained in the following list. 

1. The MS sends an SN-ACTIVATE PDP CONTEXT DEMAND 
PDU to the SwMI over the R 0 interface as defined in the TETRA PDP specifi- 
cations. This message is an SNDCP protocol message, which is indicated 

25 here with the abbreviation SN. The MS indicates the form of IP address (static 
or dynamic) it wishes to use in the element 'Address Type Identifier in De- 
mand 1 . 

2. Upon receiving the SN-ACTIVATE PDP CONTEXT DEMAND 
PDU, the SNDCP entity in the SwMI creates a TETRA PDP context. The SwMI 

30 creates a TID (Tunnel Identifier) for the requested PDP context by combining 
the ITSI with the NSAPI received from the MS. The Access Point Name (APN) 
for the ITSI is retrieved from the subscriber data in the HDB, The SNDCP layer 
entity communicates with the GTP layer via the relay layer. The DNS function- 
ality of the Intra-PLMN Backbone is used to translate the APN into the IP ad- 

35 dress of the GGSN. If the MS requests a dynamic address, then the SwMI lets 
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the GGSN allocate the dynamic address. The SwMI sends a Create PDP 
Context Request (TID, APN) to the affected GGSN. 

3. The GGSN creates a new entry (a PDP context) in its PDP con- 
text table and generates a Charging Id. The new entry allows the GGSN to 

5 route PDP PDUs between the SwMI and the external PDP network, and to 
start charging. The GGSN then returns a Create PDP Context Response mes- 
sage to the SwMI. A PDP Address (i.e. the IP address) is included if the 
GGSN allocated a PDP address. 

4. The SwMI inserts the NSAPI along with the GGSN address in its 
10 PDP context. As a result, the PDP context is created both in the GGSN and 

the SwMI, and a virtual connection or GTP tunnel is established therebetween 
in accordance with specifications of the GPRS Gn interface. The NSAPI and 
the ITSI links the PDP context to a specific SNDCP entity and TETRA PDP 
context. The relay function sends a predetermined primitive with the allocated 

15 IP address to the SNDCP layer in the SwMI. The SNDCP entity completes the 
creation of the TETRA PDP context and returns an SN-ACTIVATE PDP 
CONTEXT ACCEPT PDU to the MS. The respective SNDCP entity in the MS 
completes the creation of the TETRA PDP entity and indicates the allocated IP 
address to the IP and the application layers. A logical connection is now es- 

20 tablished between the MS and the SwMI. The PDUs, e.g. the IP datagrams, 
can now be transferred from the Ms to the SwMI and further to the GGSN, and 
similarly in the reverse direction from the GGSN to the MS. The relay function 
in the SwMI relays the packets between the logical connection legs MS-SwMI 
and SwMI-GGSN according to the PDP context information, such as TID, 

25 NSAPI, ITSI, GGSN address, IP address, etc., depending on the implementa- 
tion. The SwMI is now able to route PDP PDUs to and from the MS. The 
GGSN operates towards external networks as defined in the GPRS specifica- 
tions. 

In the above example, different PDP contexts are created for the R 0 
30 interface and the Gn interface in the SwMI. It is, however, possible to combine 
these two PDP contexts into one modified PDP context in the SNDCP layer, if 
desired. In this case the relay layer provides an interconnection between the 
SNDCP layer and the GTP tunnel. 


35 


MS-Originated PDP Context Deactivation Procedure 

An MS-originated PDP Context Deactivation procedure is illustrated 
in Figure 5. Each numbered step is explained in the following list. 
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1. The MS sends an SN-DEACTIVATE PDP CONTEXT DEMAND 
PDU to the SwMI. 

2. The SwMI sends a Delete PDP Context Request message con- 
taining the TID to the GGSN. 

5 3. The GGSN removes the PDP context. If the MS was is a dynamic 

PDP address, then the GGSN releases this PDP address and makes it avail- 
able for subsequent activation by other MSs. The GGSN returns a Delete PDP 
Context Response message containing the TID to the SwMI. 

4. The SwMI removes the PDP contexts) and returns an 
10 SN-DEACTIVATE PDP CONTEXT ACCEPT PDU to the MS. 

As a result, the PDP contexts for the R 0 and Gn interfaces are de- 
activated in the MS, SwMI and GGSN. 

SwMI-Originated PDP Context Deactivation Procedure 

An SwMI-originated PDP Context Deactivation procedure is illus- 
15 trated in Figure 6. Each numbered step is explained in the following list. 

1. The SwMI sends a Delete PDP Context Request message con- 
taining the TID to the GGSN. The SwMI may send an SN-Deactivate PDP 
Context Demand PDU before it receives a response from the GGSN. 

2. The GGSN removes the PDP context and returns a Delete PDP 
20 Context Response message containing the TID to the SwMI. If the MS is using 

a dynamic PDP address, then the GGSN releases this PDP address and 
makes it available for subsequent activation by other MSs. 

3. The SwMI sends an SN-DEACTIVATE PDP CONTEXT 
DEMAND PDU to the MS. 

25 4. The MS sends an SN-DEACTIVATE PDP CONTEXT ACCEPT 

PDU to the SwMI. 

As a result, the PDP contexts for the R„ and Gn interfaces are de- 
activated in the MS. SwMI and GGSN. 

TETRA Mobility Management 

30 As noted above, one of the advantages of the invention is that the 

TETRA PDP part of the TETRA PLMN shown in Fig.2 uses the TETRA Mobil- 
ity Management defined in the TETRA specifications. 

On the other hand, the GGSN knows the IP address of the other 
end of the GTP tunnel for each PDP context, that is, the address of the Gn 

35 interface in the SwMI (the SGSN Address field in the GGSN's PDP context). If 
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the SwMI has more that one Gn interface and the activ Gn interface changes 
while the MS roams, the SwMI must signal the corresponding GGSN to update 
the address of the Gn interface. That can be done by using the GTP signaling 
message Update PDP Context Request defined in the GPRS specifications. In 

5 order to facilitate the description of the location update signaling between the 
SwMI and the GGSN, a new entity called a Gn Gateway has been defined. 

The Gn Gateway is located inside the SwMI, and each SwMI may 
have one or several Gn Gateways. The Gn Gateway participates in the 
TETRA Mobility Management in various ways. Firstly, each Gn Gataway is re- 

10 sponsible for a group of TETRA base stations BS. The number of BSs in a 
group is dependent on the implementation and configuration concerned. The 
Gn Gateway has one or more Gn interfaces, that is, IP gateways with the GTP 
tunneling support connected to the Intra-PLMN backbone. The Gn Gateway is 
responsible for routing T-PDUs (TETRA Payload Tunneled over the GTP tun- 

15 nel) between its Gn interface and the TBSs it is responsible for. When the MS 
roams from the area of one Gn Gateway to the area of another, the new Gn 
Gateway is responsible for signaling towards the GGSN and for signaling with 
the old Gn Gateway. The signaling between the Gn Gateway and the GGSN is 
the GTP signaling, whereas the signaling between two Gn Gateways is intra- 

20 SwMI signaling, which is implementation-dependent. A typical implementation 
of the Gn gateway is to arrange it in association with a TETRA exchange DXT: 
when a serving DXT changes within the SwMI, also the Gn Gateway entity is 
changed. An SwMI with two Gn Gateways and two Gn interfaces between the 
SwMI and the Intra-PLMN backbone is illustrated in Fig. 7. 

25 Inter-Gn Gateway Location Update 

An Inter-Gn Gateway Location Update procedure is illustrated in 
Figure 8. Each step is explained in the following list. 

1. The MS roams from the area of Gn Gateway-1 to the area of Gn 
Gateway-2 shown in Fig. 7 and sends a U-LOCATION UPDATE DEMAND 

30 PDU to one of the BSs of Gn Gateway-2. 

2. An Intra-SwMI signaling between Gn Gateway-1 and Gn- 
Gateway-2 relating to the mobility management within the TETRA network. 

3. After completing the change of the Gn-Gateway within the SwMI, 
the new Gn Gateway-2 sends an Update PDP Context Request containing the 

35 IP address for the Gn interface of Gn Gateway-2 and the TID to the GGSN. 
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4. The GGSN updates its PDP context fields with the new Gn ad- 
dress and the TID and returns an Update PDP Context Response containing 
the TID. 

5. Finally, the BS of Gn Gateway-2 sends a U-LOCATION UPDATE 
5 ACCEPT PDU to the MS. 

As a result, data transfer between the MS and the GGSN can con- 
tinue through the new Gn Gateway. 

Interworking between Separate TETRA Networks 

The TETRA PLMN architecture according to the invention allows 
10 also a relatively simple interworking between separate PLMN networks, as il- 
lustrated in Fig. 9. TETRA PLMN-1 and TETRA PLMN-2 are both similar to the 
TETRA PLMN described above with respect to Fig. 2. A visitor database VDB 
is a database which comprises temporary information about individual and/or 
group subscribers and is located in the visited SwMI. The SwMIs of the sepa- 
15 rate networks are interconnected by the Inter-System Interface (ISI) defined in 
the ETS 300 392-3-1 technical specification. Thus TETRA-related mobility 
management and interworking can be carried out as defined for the TETRA. 
The Intra-PLMN Backbones of the separate PLMNS are interconnected, in ac- 
cordance with the GPRS specifications, by the Gp interface via Border Gate- 
20 ways BG. Therefore, GTP tunneling and GPRS signaling can be used be- 
tween the GGSNs in different PLMNs. For example, let us assume, that the 
MS roams from PLMN-1 to PLMN-2 while having an active connection to the 
GGSN1. The SwMI-1 and the SwMI will firstly carry out an inter-PLMN hando- 
ver using the TETRA-specific ISI signaling. At the same time, the Gn Gateway 
25 is also changed. The new Gn gateway obtains the GGSN address in the ISI 
signaling and then sends the Update PDP Context Request (containing the IP 
address for the Gn interface of the new Gn Gateway and the TID) to the 
GGSN1 via BG2, Gp interface and BG1. The GGSN1 updates its PDP context 
fields with the new Gn address and the TID and returns an Update PDP Con- 
30 text Response containing the TID. Thus, a GTP tunnel is established between 
the SwMI-2 and the GGSN1. No new interfaces or signaling protocols are 
needed for supporting the mobility and routing in the inter-PLMN roaming. 

The Gn interface and the GGSN, which conform to the GPRS 
specifications, allow interworking with other networks as well, such the UMTS 
35 (Universal Mobile Communications System) or the GSM (Global System for 
Mobile communication) supporting the GPRS operation. 
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The description only illustrates preferred embodiments of the inv n- 
tion. The invention is not, however, limited to these examples, but it may vary 
within the scope and spirit of the appended claims. 
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Claims 

1. A mobile communications network, comprising 

a plurality of mobile stations (MS) having a packet data capability, 
a switching and management infrastructure (SwMI) having a mobil- 
5 ity management capability for the mobile stations (MS) which have a logical 

packet data connection of a first type activated between said infrastructure 

(SwMI) and the respective mobile station (MS), 
characterized by 

a gateway packet node (GGSN) connected to said switching and 
10 management infrastructure (SwMI) by means of a standard interface (Gn) ini- 
tially defined to be used between packet nodes in another packet radio net- 
work in order to provide a packet mode connection to an external communica- 
tions network (PDN), 

said switching and management infrastructure (SwMI) and the 
15 gateway packet node (GGSN) being arranged to activate a logical packet data 
connection of a second type and to tunnel data packets between the infra- 
structure (SwMI) and the gateway packet node (GGSN) according to protocols 
and signaling messages defined for said standard interface (Gn). 

2. A communications network as claimed in claim 1, charac- 
20 terized in that 

said logical connection of the first type is activated in a network- 
layer protocol layer (SNDCP) between the mobile station (MS) and the 
switching and management infrastructure (SwMI), 

said logical connection of the second type is activated in a tunneling 
25 protocol layer (GTP) at said standard interface (Gn), 

said switching and management infrastructure (SwMI) includes a 
relaying function (Relay) for relaying data packets and adapting the signaling 
protocols (SNDCP, GTP) between said logical connections of the first and the 
second type in order to provide an end-to-end data transfer and end-to-end 
30 signaling procedures for activation and deactivation of the logical connections 
between the mobile station (MS) and the gateway packet node (GGSN). 

3. A communications network as claimed in claim 1 or 2, char- 
acterized in that said switching and management infrastructure (SwMI) 
includes a relaying function which maps the identifiers of said logical connec- 

35 tions together. 
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4. A communications network as claimed in claim 1, 2 or 3, c h a r- 
a c t e r i z e d in that said switching and management infrastructure (SwMI) is 
arranged to derive a subscriber identity or a tunnel identity used at the stan- 
dard interface protocols from a subscriber identity and/or a logical connection 

5 identity used in the switching and management infrastructure (SwMI). 

5. A communications network as claimed in any one of claims 1 to 
4, characterized in that said standard interface includes at least a part 
of a Gn interface according to ETSI technical specification GSM 09.60 V7.0.0 
(1999-04). 

10 6. A communications network as claimed in claim 5, charac- 

terized in that said switching and management infrastructure (SwMI) sup- 
ports at least the following tunneling protocol (GTP) messages in the Gn in- 
terface: Create PDP Context Request, Create PDP Context Response, Up- 
date PDP Context Request, Update PDP Context Response, Delete PDP 

15 Context Request and Delete PDP Context Response. 

7. A communications network as claimed in claim 6, charac- 
terized in that said switching and management infrastructure (SwMI) fur- 
ther supports the following tunneling protocol (GTP) messages in the Gn in- 
terface: Echo Request, Echo Response, Version Not Supported and Error In- 

20 dication. 

8. A communications network as claimed in any one of claims 1 to 

7, characterized in that said switching and management infrastructure 
(SwMI) comprises two or more internal gateway entities (Gn Gateway-1,-2) 
each having said standard interface (Gn) to said gateway packet node 

25 (GGSN), and that said switching and management infrastructure (SwMI) is ar- 
ranged to change the internal gateway entity by means of an internal signaling 
and mobility management when a mobile station (MS) roams within the infra- 
structure (SwMI), and that the new internal gateway entity is arranged to signal 
the address of the new gateway entity to said gateway packet node (GGSN) 

30 so as to update the logical packet data connection of the second type. 

9. A communications network as claimed in any one of claims 2 to 

8, characterized in that said switching and management infrastructure 
(SwMI-1) comprises a signaling interface (Gn) to a similar switching and man- 
agement infrastructure (SwMI-2) in a separate mobile communications net- 

35 work (TETRA PLMN-2), and that said gateway packet node (GGSN-1) has a 
second standard interface (Gp) to a similar gateway packet node (GGSN-2) in 
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said separate mobile communications network, said second standard interface 
(Gp) being initially defined to be used between gateway packet nodes in said 
other mobile communications network. 

10. A method of establishing packet mode communication from a 
5 mobile communications network (TETRA PLMN) to external communications 

networks (PDN), said mobile communications network comprising a plurality of 
mobile stations (MS) and a switching and management infrastructure (SwMI), 
said method comprising the steps of 

activating a packet protocol context between a mobile station (MS) 
10 and the switching and management infrastructure (SwMI) with a infrastructure- 
specific network-layer protocol (SNDCP), 

using the mobility management of the switching and management 
infrastructure (SwMI) for managing the mobility of the mobile station (MS) 
having the packet protocol context, 
15 c h a r a c t e r i z e d by the further steps of 

interconnecting the switching and management infrastructure 
(SwMI) to a gateway packet node (GGSN) by means of a standard interface 
(Gn) initially defined to be used between packet nodes in another packet net- 
work, 

20 using protocols and signaling messages defined for said standard 

interface (Gn), for activating packet data protocol context between the switch- 
ing and management infrastructure (SwMI) and the gateway packet node 
(GGSN). 

11. A method as claimed in claim 10, characterized in that 
25 said standard interface includes at least a part of a Gn interface according to 

ETSI technical specification GSM 09.60 V7.0.0 (1999-04). 
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